Cellular operators are motivated to integrate WiFi access into their existing cellular networks to help meet market demand and increase their competitive edge. Many mobile devices have dual mode (WiFi and cellular) capability. The WiFi Alliance is currently defining a Hotspot 2.0 specification to help dual mode or WiFi-only devices better select a compatible WiFi network that is owned by, subscribed to, or has roaming relationship with the device's cellular operator. This network selection technology may be based on IEEE 802.11u. The Third Generation Partnership Project (3GPP) also defines several mechanisms for a mobile device to select a wireless local area network (WLAN) (e.g., in fixed network) via operator-defined policies that may be statically pre-configured on the UE or dynamically set via an Access Network Discovery and Selection Function (ANDSF) within the network.
To connect to WiFi and cellular networks, devices generally use authentication procedures (e.g., based on a subscriber identity module (SIM) card), which may be carried out seamlessly with little to no input required from the end-user. When devices switch between a WiFi and cellular network or between different WiFi networks, access attempts may lead to a large amount of signalling traffic, for example, during authentication storms. During authentication storms, many authentication requests are sent to the network by multiple devices near one location. The influx of authentication requests may overload affected access networks (ANs) and authentication servers. Authentication storms may be caused by numerous issues with current authentication procedures. For example, authentication procedures are carried out by a device each time it moves to a new AN. Devices that do not have Wi-Fi in its subscription plan may still attempt to authenticate. Authentication storms may also be caused by rapid movement of many devices between different ANs in a short period of time.
There are various proposed solutions to address the issue of authentication storms, and these include solutions on both the network side and the device side. For solutions on the device side, a user equipment (UE) needs to be aware of the overload situation in the authentication server so that the UE may respond accordingly. However, current UEs lack a mechanism to know of an overload before the UE starts an authenticate procedure with the overloaded server, at which time it may be too late for the UE to respond accordingly. Furthermore, when the authentication server is overloaded, it may better for the network to control or influence UE behaviour to avoid worsening the situation. However, current networks lack a mechanism for controlling or influencing UE authentication behaviour.